The present invention relates to the transmission of video signals over telecommunications networks, and more particularly to a method of controlling the transmission of multiple steams over a congested network so that each stream receives an equitable share of the bandwidth dependent on the quality of the encoding.
Transmission of video data networks, such as the Internet, is commonplace today. To receive such signals, a user can use a suitably configured computer or other receiver such as a “set top box” (STB). STBs have become increasingly popular and many are provided with an IP connection allowing content such as video to be streamed or downloaded over the Internet. Television delivered over the Internet, commonly referred to as IPTV, is a good example of this growing service.
When streaming video data over an IP network, there are no guarantees that the data sent will reach its destination. When the network experiences congestion and other problems, delays will occur to the transmission of the data packets and some packets may even be lost.
To provide more reliable end-to-end delivery of data, the transmission control protocol (TCP) is often used as the transport protocol. Indeed, it is quite common to use TCP in video streaming systems for a number of reasons, but primarily because TCP provides mechanisms for ensuring reliable delivery, and managing network congestion. For example, one way in which TCP achieves reliability is by obliging the receiver to acknowledge to the sender any data received. If a packet of data remains unacknowledged after a predetermined period of time, TCP assumes the packet was not received and the same packet is retransmitted by the sender. One way that TCP manages congestion is by reducing the transmission rate of data as a function of congestion in the network.
For example, where a number of video streams are being delivered using TCP and all share a contended piece of network, when congestion occurs, the TCP congestion control algorithm will force all of the streams to reduce their transmission rate to allow congestion to clear. Each stream is reduced by a fixed factor and eventually all streams will stabilize at approximately the same bandwidth (assuming a similar round trip time). Use of such a method is not without problems as delays to segments of the video streams are particularly undesirable. This can be mitigated at least in part using various techniques such as using receiver buffers and dropping occasional segments and relying on error recovery techniques instead.
Video streams are also sometimes delivered at a variable bitrate over TCP. However, the above congestion scenario may still occur, and two streams each having a different bit rate will still stabilise to roughly the same reduced bitrate when the network is congested. This may result in some particularly undesirable results when a first stream is initially encoded at a high bitrate, for example a video sequence with high frame activity such as a sports sequence, and a second sequence is encoded at a low bitrate, for example a video sequence with a low frame activity such as a news or drama sequence.
When congestion is experienced on the network, TCP will cut the available bandwidth for both streams to roughly the same level. This will affect the first stream, which was encoded at a higher bitrate and this has a higher bandwidth requirement, more than the second stream which might have been encoded at a low bitrate stream. In other words, the first, high bitrate, stream will be more significantly affected than the second, low bitrate, stream as the first stream is given the same reduced bandwidth as the second stream. This will cause the quality of the video delivered to each user to vary over time, and the quality to vary from user to user depending on the type of video clip they are viewing.
Another way of streaming video that mitigates some of these problems experienced under TCP is to use a constant bitrate delivery system where the bitrate available to a video stream is fixed, for example by a reservation scheme, before the transmission of data starts. This method of delivery is easier to manage, but is not without its problems.
Again, taking the example of the two video streams above, where we have a first stream that has very active frames such as a sports clip, and a second stream with less active frames such as a news clip. The bitrate reserved and used to deliver the two streams are fixed at a predetermined rate (that is considered to be sufficient for most applications and in this case for both streams). However, the second stream will not actually require that much bandwidth as the bitrate of the encoding can be much lower that that of the first sequence given that the activity in the second sequence is much less. The second stream transmitted using this fixed bandwidth is thus wasting much of its allocated bandwidth. If the second stream increases the encoding rate so as to utilise the entire bandwidth reserved, the quality of the resulting video is likely to be much higher than the first stream. However, this increase in quality may not necessarily be significant as perceived from the viewer and may thus be wasted. Moreover, this redundant bandwidth is not an efficient use of network resources.
The problems above are heightened when video sequences vary in activity during the sequence. For example, a relatively static news reading sequence might be interspersed with highlights of a football clip which shows a lot of activity.
One known method for streaming video content involves using a dedicated streaming server. These servers are configured to provide streamed content such as video to receivers and furthermore have the capability to monitor the network link to the receivers and adjust the quality of the stream being delivered. However such servers are not supported by all content delivery networks and require a dedicated equipment and setup by the content provider.
HTTP streaming has been developed to emulate the effects of a dedicated streaming server. This is advantageous as HTTP traffic is generally not blocked by firewalls and the content delivery network is adapted to handling HTTP traffic. However, HTTP streaming is limited in that it does not support streaming data as it is being encoded. Also, the HTTP server is not aware of the receiving client's network conditions. It simply serves data in response to a client request. Therefore in order to carry out adaptive streaming using HTTP streaming, a complete video sequence must be encoded at several qualities (or bitrates) and then segmented into chunks, each representing a fixed duration of video. Typically these chunks will be several seconds long. To stream a particular video sequence, the client will send a request to the server containing the identity of a particular chunk of video in dependence on the current available bandwidth on the network. The HTTP server merely fetches the requested video chunk over the network link.